bpo-36384: Leading zeros in IPv4 addresses are no longer tolerated (GH-25099) (GH-25815)
Reverts commit e653d4d8e820a7a004ad399530af0135b45db27a and makes
parsing even more strict. Like socket.inet_pton() any leading zero
is now treated as invalid input.
Signed-off-by: Christian Heimes <christian@python.org> Co-authored-by: Łukasz Langa <lukasz@langa.pl>
(cherry picked from commit 60ce8f0be6354ad565393ab449d8de5d713f35bc)
Gbp-Pq: Name 0009-bpo-36384-Leading-zeros-in-IPv4-addresses-are-no-lon.patch
gh-87389: Fix an open redirection vulnerability in http.server. (GH-93879) (GH-94093)
Fix an open redirection vulnerability in the `http.server` module when
an URI path starts with `//` that could produce a 301 Location header
with a misleading target. Vulnerability discovered, and logic fix
proposed, by Hamza Avvan (@hamzaavvan).
bpo-43285 Make ftplib not trust the PASV response. (GH-24838)
bpo-43285: Make ftplib not trust the PASV response.
The IPv4 address value returned from the server in response to the PASV command
should not be trusted. This prevents a malicious FTP server from using the
response to probe IPv4 address and port combinations on the client network.
Instead of using the returned address, we use the IP address we're
already connected to. This is the strategy other ftp clients adopted,
and matches the only strategy available for the modern IPv6 EPSV command
where the server response must return a port number and nothing else.
For the rare user who _wants_ this ugly behavior, set a `trust_server_pasv_ipv4_address`
attribute on your `ftplib.FTP` instance to True.
(cherry picked from commit 0ab152c6b5d95caa2dc1a30fa96e10258b5f188e)
Co-authored-by: Gregory P. Smith <greg@krypto.org>
Gbp-Pq: Name 0007-bpo-43285-Make-ftplib-not-trust-the-PASV-response.-G.patch
bpo-43075: Fix ReDoS in urllib AbstractBasicAuthHandler (GH-24391) (GH-25247)
Fix Regular Expression Denial of Service (ReDoS) vulnerability in
urllib.request.AbstractBasicAuthHandler. The ReDoS-vulnerable regex
has quadratic worst-case complexity and it allows cause a denial of
service when identifying crafted invalid RFCs. This ReDoS issue is on
the client side and needs remote attackers to control the HTTP server.
(cherry picked from commit 7215d1ae25525c92b026166f9d5cac85fb1defe1)
Co-authored-by: Yeting Li <liyt@ios.ac.cn> Co-authored-by: Yeting Li <liyt@ios.ac.cn>
Gbp-Pq: Name 0004-bpo-43075-Fix-ReDoS-in-urllib-AbstractBasicAuthHandl.patch
bpo-42988: Remove the pydoc getfile feature (GH-25015)
CVE-2021-3426: Remove the "getfile" feature of the pydoc module which
could be abused to read arbitrary files on the disk (directory
traversal vulnerability). Moreover, even source code of Python
modules can contain sensitive data like passwords. Vulnerability
reported by David Schwörer.
(cherry picked from commit 9b999479c0022edfc9835a8a1f06e046f3881048)
Co-authored-by: Victor Stinner <vstinner@python.org>
Gbp-Pq: Name 0003-bpo-42988-Remove-the-pydoc-getfile-feature-GH-25015.patch
[3.9] gh-95778: CVE-2020-10735: Prevent DoS by very large int() (#96502)
* Correctly pre-check for int-to-str conversion (#96537)
Converting a large enough `int` to a decimal string raises `ValueError` as expected. However, the raise comes _after_ the quadratic-time base-conversion algorithm has run to completion. For effective DOS prevention, we need some kind of check before entering the quadratic-time loop. Oops! =)
The quick fix: essentially we catch _most_ values that exceed the threshold up front. Those that slip through will still be on the small side (read: sufficiently fast), and will get caught by the existing check so that the limit remains exact.
The justification for the current check. The C code check is:
```c
max_str_digits / (3 * PyLong_SHIFT) <= (size_a - 11) / 10
```
In GitHub markdown math-speak, writing $M$ for `max_str_digits`, $L$ for `PyLong_SHIFT` and $s$ for `size_a`, that check is:
$$\left\lfloor\frac{M}{3L}\right\rfloor \le \left\lfloor\frac{s - 11}{10}\right\rfloor$$
From this it follows that
$$\frac{M}{3L} < \frac{s-1}{10}$$
hence that
$$\frac{L(s-1)}{M} > \frac{10}{3} > \log_2(10).$$
So
$$2^{L(s-1)} > 10^M.$$
But our input integer $a$ satisfies $|a| \ge 2^{L(s-1)}$, so $|a|$ is larger than $10^M$. This shows that we don't accidentally capture anything _below_ the intended limit in the check.
Co-authored-by: Gregory P. Smith [Google LLC] <greg@krypto.org> Co-authored-by: Christian Heimes <christian@python.org> Co-authored-by: Mark Dickinson <dickinsm@gmail.com>
Gbp-Pq: Name 0002-3.9-gh-95778-CVE-2020-10735-Prevent-DoS-by-very-larg.patch
# DP: Description: support alternative gettext tree in
# DP: /usr/share/locale-langpack; if a file is present in both trees,
# DP: prefer the newer one
# DP: Upstream status: Ubuntu-Specific
# DP: Description: support alternative gettext tree in
# DP: /usr/share/locale-langpack; if a file is present in both trees,
# DP: prefer the newer one
# DP: Upstream status: Ubuntu-Specific
# DP: Get CONFIGURE_CFLAGS, CONFIGURE_CPPFLAGS, CONFIGURE_LDFLAGS from
# DP: the python build, when CFLAGS, CPPFLAGS, LDSHARED) are not set
# DP: in the environment.
# DP: Get CONFIGURE_CFLAGS, CONFIGURE_CPPFLAGS, CONFIGURE_LDFLAGS from
# DP: the python build, when CFLAGS, CPPFLAGS, LDSHARED) are not set
# DP: in the environment.
# DP: distutils: Add an option --install-layout=deb, which
# DP: - installs into $prefix/dist-packages instead of $prefix/site-packages.
# DP: - doesn't encode the python version into the egg name.
# DP: distutils: Add an option --install-layout=deb, which
# DP: - installs into $prefix/dist-packages instead of $prefix/site-packages.
# DP: - doesn't encode the python version into the egg name.
* Revert fixes for CVE-2025-15366 and CVE-2025-15367. It was found that
those changes break backward compatibility, and upstream didn't backport
it to any branch. More details can be found in discussions on the upstream
bugtracker (issues and merge requests).
* Apply upstream patch for the following CVE:
- CVE-2026-6100: Use-after-free (UAF) was possible in the
`lzma.LZMADecompressor` and `bz2.BZ2Decompressor` when a memory
allocation fails with a `MemoryError` and the decompression instance is
re-used. This scenario can be triggered if the process is under memory
pressure.
projects / python3.9.git / log